Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add car ferry functionality #5966

Merged
merged 16 commits into from
Oct 29, 2024

Conversation

VillePihlava
Copy link
Contributor

@VillePihlava VillePihlava commented Jul 11, 2024

Summary

This PR adds the carry ferry feature. Using this feature requires compatible GTFS data with the cars_allowed field in the trips.txt file. This field is used similarly to how bikes_allowed is used. Also { "modes": "CAR" } should be added to the transferRequests section of the build-config.json file.

Things that have been manually tested include:

  • Using a ferry on a trip with a car
  • Using multiple ferries on a trip with a car

Things that are not in the scope of this pr:

  • Compatibility with Netex.
  • More configurability for car transfers (e.g. changing transferRequests to allow for vehicle-specific maxTransferDuration).

Issue

Closes #5875

Unit tests

Added.

Documentation

No documentation has been added.

Bumping the serialization version id

Needed.

@leonardehrenfried
Copy link
Member

This looks already quite promising.

Under which conditions should a stop be linked to a drivable edge? Do you want to make it explicit in the transit data or do you want infer it from the fact that a car-enabled route stops there?

@VillePihlava
Copy link
Contributor Author

VillePihlava commented Jul 11, 2024

Under which conditions should a stop be linked to a drivable edge? Do you want to make it explicit in the transit data or do you want infer it from the fact that a car-enabled route stops there?

This is a good question. We have discussed this quite a lot and the question remains somewhat open. The information for stops can be inferred from a car-enabled ferry using the stop as you said. At least currently I'll try to go with that. However, there is some discussion on changing the gtfs standard related to this here: google/transit#466. Depending on how the discussion progresses will also affect this quite a lot. The changes might also affect the bikes_allowed field and others, so doing something like this could work:

Adding just cars_allowed to trips.txt in the onebusaway repository
-> initial implementation in OTP with just cars_allowed
-> waiting for the final version of the car ferry changes to the gtfs standard
-> changing everything related at the same time (cars, bikes, wheelchairs, etc)

@VillePihlava VillePihlava force-pushed the car-ferry-changes branch 2 times, most recently from 7292d80 to fb9e985 Compare September 3, 2024 13:31
@VillePihlava VillePihlava changed the title Add car ferry feature [DRAFT] Add car ferry functionality Sep 3, 2024
@VillePihlava
Copy link
Contributor Author

@t2gran @optionsome @leonardehrenfried assuming possible changes to transfers (e.g. changing transferRequests to allow for vehicle-specific maxTransferDuration) will be split into a separate pr, this pr is now essentially ready-to-review. I will open this pr when a new release has been created from the https://github.com/OneBusAway/onebusaway-gtfs-modules library and OTP uses it.

@leonardehrenfried
Copy link
Member

Has been released: https://github.com/OneBusAway/onebusaway-gtfs-modules/releases

@VillePihlava VillePihlava marked this pull request as ready for review September 9, 2024 11:41
@VillePihlava VillePihlava requested a review from a team as a code owner September 9, 2024 11:41
@optionsome optionsome added bump serialization id Add this label if you want the serialization id automatically bumped after merging the PR New Feature labels Sep 10, 2024
Copy link

codecov bot commented Sep 11, 2024

Codecov Report

Attention: Patch coverage is 88.40580% with 8 lines in your changes missing coverage. Please review.

Project coverage is 69.95%. Comparing base (a574bc3) to head (02aaf42).
Report is 28 commits behind head on dev-2.x.

Files with missing lines Patch % Lines
...fs/mapping/routerequest/ModePreferencesMapper.java 0.00% 1 Missing and 1 partial ⚠️
...is/gtfs/mapping/routerequest/AccessModeMapper.java 0.00% 1 Missing ⚠️
...is/gtfs/mapping/routerequest/EgressModeMapper.java 0.00% 1 Missing ⚠️
.../gtfs/mapping/routerequest/TransferModeMapper.java 0.00% 1 Missing ⚠️
...er/apis/transmodel/mapping/RequestModesMapper.java 66.66% 0 Missing and 1 partial ⚠️
.../opentripplanner/gtfs/mapping/CarAccessMapper.java 83.33% 1 Missing ⚠️
...request/RouteRequestTransitDataProviderFilter.java 83.33% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             dev-2.x    #5966   +/-   ##
==========================================
  Coverage      69.94%   69.95%           
- Complexity     17744    17762   +18     
==========================================
  Files           1998     2000    +2     
  Lines          75454    75505   +51     
  Branches        7723     7728    +5     
==========================================
+ Hits           52778    52818   +40     
- Misses         20007    20012    +5     
- Partials        2669     2675    +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@leonardehrenfried
Copy link
Member

@optionsome I don't think we assigned reviewers yesterday, correct?

@tsherlockcraig
Copy link
Contributor

I just posted to google/transit#466 in favor of the alternate approach that had been offered there by miklcct.

If the work for cars_allowed has already been performed, and the OTP developers don't believe switching to the alternate approach is feasible in the near term, we could potentially move forward with this as a "private extension" between GTFS producers and OTP. I do agree that cars_allowed would be slightly easier for WSDOT as a producer, but the boarding_permissions.txt approach is also reasonably simple, and more durable/extendable.

@VillePihlava
Copy link
Contributor Author

@tsherlockcraig I posted a reply in the issue you mentioned. The arguments in that thread centered around adding changes to trips.txt + boarding_permissions.txt or just adding boarding_permissions.txt alone. For some cases, getting more detailed information from GTFS is nice.

This implementation should be enough for many cases. Extending this functionality, especially since it is based on an experimental onebusaway GTFS library addition (cars_allowed), would not be unreasonable :).

Also, for example, Netex support has not been implemented, so at some point development related to car ferries should come from that angle.

@@ -3062,6 +3073,11 @@ enum PlanAccessMode {
"""
BICYCLE_RENTAL
"""
Driving a car from the origin to the destination.
TODO add more thorough description
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please resolve these TODOs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODOs are now resolved, the comments are based on the assumption that the access, egress, and transfer modes should all be equal when one is set to CAR. Once the issue brought up by Henrik is solved this might have to be changed

@@ -2268,6 +2268,8 @@ type Trip implements Node {
"Whether bikes are allowed on board the vehicle running this trip"
bikesAllowed: BikesAllowed
blockId: String
"Whether cars are allowed on board the vehicle running this trip"
carsAllowed: CarsAllowed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you actually need this information in your UI? If not I would remove that field because we don't know how the standardisation process will play out.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this

Comment on lines 13 to 20
switch (carsAllowed) {
case 1:
return CarAccess.ALLOWED;
case 2:
return CarAccess.NOT_ALLOWED;
default:
return CarAccess.UNKNOWN;
}
Copy link
Member

@leonardehrenfried leonardehrenfried Sep 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
switch (carsAllowed) {
case 1:
return CarAccess.ALLOWED;
case 2:
return CarAccess.NOT_ALLOWED;
default:
return CarAccess.UNKNOWN;
}
return switch (carsAllowed) {
case 1 -> CarAccess.ALLOWED;
case 2 -> CarAccess.NOT_ALLOWED;
default -> CarAccess.UNKNOWN;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to this

Comment on lines 107 to 129
Set<StopLocation> stopLocationsUsedForCarsAllowedTrips = Set.of();
stopLocationsUsedForCarsAllowedTrips =
transitModel
.getAllTripPatterns()
.stream()
.filter(t ->
t
.getScheduledTimetable()
.getTripTimes()
.stream()
.anyMatch(tt -> tt.getTrip().getCarsAllowed() == CarAccess.ALLOWED)
)
.flatMap(t -> t.getStops().stream())
.collect(Collectors.toSet());

stopLocationsUsedForCarsAllowedTrips.addAll(
stopLocationsUsedForCarsAllowedTrips
.stream()
.filter(GroupStop.class::isInstance)
.map(GroupStop.class::cast)
.flatMap(g -> g.getChildLocations().stream().filter(RegularStop.class::isInstance))
.toList()
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you extract that into a method and convert the line comments to Javadoc?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, can also extract a method for the flex stops?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created methods for both in the transitModel. This will also be useful later when working on the transferRequest stuff related to cars on transit

assertTrue(model.stopVertex().isConnectedToGraph());

// Because the stop is used by a carsAllowed trip it needs to be linked to both the walk and car edge
assertEquals(2, model.stopVertex().getOutgoing().size());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
assertEquals(2, model.stopVertex().getOutgoing().size());
assertThat(model.stopVertex().getOutgoing()).hasSize(2);

Since I wrote this other test, we introduced the truth assertion library.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed all assertEquals in this file to assertThat

@leonardehrenfried
Copy link
Member

@optionsome can merge when HSL is ready.

@optionsome
Copy link
Member

Lets wait a bit before merging this in. We need to do a production release of our fork first and then we will quickly test this in our dev to see that this doesn't cause any problems.

@VillePihlava
Copy link
Contributor Author

Final merge conflict resolve. According to @optionsome this can now be merged.

@optionsome optionsome merged commit 1377722 into opentripplanner:dev-2.x Oct 29, 2024
5 checks passed
@optionsome optionsome deleted the car-ferry-changes branch October 29, 2024 21:37
t2gran pushed a commit that referenced this pull request Oct 29, 2024
t2gran pushed a commit that referenced this pull request Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bump serialization id Add this label if you want the serialization id automatically bumped after merging the PR New Feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for car ferries
6 participants